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ABSTRACT 

An  ADA-like  language  is  proposed  as  a  high  level,  specification 
oriented  modeling  tool.  It  is  asserted  that  the  very   early  system  design 
modeling  tasks  are  typically  not  given  adequate  stress,  with  the  result 
that  poor  system  designs  are  carried  forward  into  the  mid  design  phases. 
A  lack  of  suitable  modeling  tools  is  likely  one  reason,  and  so  an  ADA-like 
modeling  technique  is  proposed.  It  has  many  of  the  properties  of  speci- 
fication languages,  including  the  ability  to  be  machine  processed  to  indi- 
cate incomplete  or  inconsistant  systems.  The  unclassified  portions  of  the 
SPY-1  radar  component  of  the  AEGIS  weapon  system  is  used  as  a  test  vechicle 
to  illustrate  the  modeling  technique. 
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I  Purpose  of  the  Research 

This  research  evaluates  the  use  of  the  new  DoD  programming 
language  ADA  [Ichbiah79,  Wegner801  (or  an  ADA-like  language)  as  a 
modeling  technique  for  large  scale  multiprocessing  computer  sys- 
tems. In  particular,  the  research  is  to  evaluate  the  effective- 
ness of  such  a  modeling  technique  vis-a-vis  other,  more  conven- 
tional techniques  such  as  flowcharts,  block  diagrams,  and  narra- 
tives. The  measure  of  effectiveness  is  a  qualitative  assessment 
of  its  ease  of  use  and  understandibi li ty  by  designers  and  "custo- 
mers" (the  purchasers  of  the  modelled  system). 

II  Background 

The  ADA  language  is  currently  undergoing  final  definition  as 
the  new  standard  DoD  embedded  systems  language.  ADA,  when 
adopted,  will  be  the  standard  language  for  programming  computers 
that  are  components  in  weapon  systems.  The  language  incorporates 
the  latest  concepts  in  algorithmic  language  design,  including 
modern  control  structures,  user-defined  data  types,  and  the  abil- 
ity to  coordinate  concurrently  executing  "tasks".  As  of  this 
writing  no  production  ADA  compiler  exists,  and  so  the  ADA  pro- 
grams included  in  this  report  have  not  been  verified  as  being 
syntactically  or  semantically  correct. 

A  major  problem  with  all  large  scale  systems  (multiprocessing 
systems  like  AEGIS  in  particular)  is  the  early  design  phase  in 
which  customer  requirements  are  specified.  Typically  system 
development   is   retarded  and  budgets  exceeded  because  the  system 
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is  incompletely  or  incorrectly  specified. 

One  reason  a  system  may  become  incompletely  or  incorrectly 
soecified  is  the  lack  of  sufficient  communication  between  the 
designers  of  the  system  (technical  persons)  and  the  buyer  or  cus- 
tomer of  the  system  (the  persons  with  the  problem  the  system  is 
meant  to  resolve).  Due  to  their  different  knowledge  of  the  prob- 
lem these  two  groups  have  a  different  perception  and  understand- 
ing of  the  problem,  and  yet  the  design  of  a  successful  system 
largely  depends  upon  how  closely  the  perceptions  can  be  brought 
together.  Unfortunately,  because  of  these  mispercept ions ,  the 
designers  proceed  with  a  system  that  satisfies  the  problem  as 
they  understand  it,  and  the  customer  is  unaware  of  this  because 
of  the  lack  of  communication.  At  some  point  the  difference  is 
discovered,  but  usually  after  much  effort  has  been  wasted.  Better 
communication  is  a  solution  to  this  problem,  and  a  candidate 
mechanism  for  this  purpose  is  a  modeling  technique  more  under- 
standable by  both  the  designers  and  the  customers.  Computer  sci- 
ence specialists,  known  as  software  engineers,  have  been  and  are 
developing  tools  to  deal  with  this  problem  [Teich77,  Davis79, 
Jones79] .  Collectively  these  tools  are  called  "specification 
languages",  and  are  usually  interactive  programming-like 
languages  that  can  be  computer  processed  to  indicate  specifica- 
tion related  problems. 

It  is  asserted  here  that  ADA  (or  an  ADA-like  language)  can  be 
used  as  a  specification  tool.  This  results  from  the  ability  of 
ADA  to  allow  top-down  program  development,  in  which  functionality 
can   be   omitted   at   a   high  level,  only  to  be  incorporated  at  a 
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later  time.  In  addition,  ADA  incorporates  control  structures  for 
multitasking,  in  which  concurrently  executing  tasks  are  coordi- 
nated in  a  specified  way.  Information  may  be  passed  among  the 
tasks  in  a  manner  which  is  independant  of  the  underlying  computer 
architecture  (shared  memory  or  distributed  processing) .  If  ADA 
proves  useful  in  this  role  the  conversion  of  the  specifications 
into  executable  code  would  be  less  costly  and  quicker  than  other- 
wise possible,  a  worthwhile  objective. 

Other  commonly  used  programming  languages,  such  as  PL/I,  For- 
tran, or  CMS-2,  could  also  be  a  basis  of  a  modeling  tool.  However 
ADA  has  most  of  the  good  features  of  those  languages  and  some 
additional  features  as  well.  This  is  not  unexpected  as  ADA  is 
meant  to  be  a  contemporary  refinement  of  all  that  is  known  about 
programming  languages.  For  example  ADA's  multitasking  capability 
is  a  more  modern  mechanism  than  the  equivalent  in  PL/T .  Thus  ADA 
aopears  to  be  the  best  notation  upon  which  to  build  a  high  level 
modeling  tool. 

In  the  remaining  sections  of  this  report  the  derivation  of  an 
ADA-like  model  of  SPY-1  is  accomplished.  The  narrative  accompany- 
ing the  derivation  is  meant  to  exhibit  the  derivation  thought 
process,  and  assumes  at  least  some  familiarity  with  contemporary 
programming  language  practices  and  concepts. 

Ill   The  Research  Vehicle 

The  SPY-1  radar  component  of  the  AEGIS  weapon  system  is 
chosen  as  a  research  vehicle  for  several  reasons.  First,  it  is  an 
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ongoing  research  project  at  the  Naval  Postgraduate  School,  where 
three  faculty  members  and  several  graduate  students  are  investi- 
gating a  microprocessor  based  multiprocessing  implementation  of 
SPY-1.  Secondly  another  faculty  member  (the  author)  has  the 
requisite  knowledge  of  ADA  and  is  interested  in  the  research 
topic.  Fortunately  enough  unclassified  documentation  of  SPY-1 
exists  for  meaningful  research  to  be  carried  out.  Finally  the 
project  is  small  enough  to  allow  current  funding  to  be  used. 

The  source  of  information  for  the  research  is  almost  entirely 
from  a  classified  report  [WS-105441  with  all  the  classified  pages 
removed.  The  omitted  information  results  in  some  gaps  in  the 
study,  but  not  enough  to  affect  the  modeling  effort.  In  the 
remaining  sections  this  document  is  referred  to  as  the  "refer- 
enced document"  or  "referenced  source". 

In  the  next  section  an  overall  summary  of  the  SPY-1  radar 
system  and  its  interface  with  other  AEGIS  components  is 
presented. 

IV  The  SPY-1  Radar 

This  section  describes  the  SPY-1  radar  system  at  the  highest 
level.  The  information  is  derived  from  the  document  referenced 
above,  consisting  mostly  of  a  narrative  with  accompanying  tables 
and  diagrams. 

At  the  highest  level  the  SPY-1  interfaces  with  other  AEGIS 
components,  namely  a  Command  and  Control  System,  a  Weapons  Con- 
trol System,  an  Operational   Readiness   Test   System,   a   Missile 
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Datalink  System,  and  a  Gun  Fire  Control  System.  Interfaces  are 
defined  to  these  components  in  the  form  of  data  structures;  in 
some  cases  the  details  are  classified.  In  addition  an  interface 
with  the  AEGIS  Tactical  Executive  System  is  maintained.  Listing 
1  shows  how  ADA  might  be  used  to  describe  this  level  of  detail. 

PACKAGE  spy_l  IS 

USE  interf ace_types_package;  —  global  messages 

PROCEDURE  c&d_interf ace  (  parameters  ) 

PROCEDURE  wcs_interface  (  parameters  ) 

PROCEDURE  orts_interface  (  parameters 

PROCEDURE  gfcs_interf ace  (  parameters 

PROCEDURE  ates_interf ace  (  parameters 
PRIVATE 

—  declaration  of  all  private  data  types 

—  and  private  data  objects,  not  important 

—  at  this  point  in  the  modeling  effort 
END  spy  1; 


—  classified 

—  classified 

—  classified 


Listing  1.  An  ADA  package  specification  for  SPY-1 . 

The  reader  is  reminded  that  the  ADA-like  model  derived  in  the 
following  paragraphs  only  represents  a  logical  explanation  of  the 
SPY-1  radar  system,  and  that  no  particular  underlying  computer 
architecture  need  be  assumed.  Thus  it  is  not  meaningful  (at  this 
stage  of  modeling)  to  think  of  procedures  or  tasks  as  being 
dynamically  loaded,  etc.;  the  essential  point  is  that  they  are 
invoked  when  needed  and  execute  according  to  the  ADA  language 
semantics . 

Before  discussing  this  ADA-like  code,  the  notion  of  a  "pack- 
age" is  defined.  In  ADA  a  package  is  a  means  of  grouping  related 
items  together,  typically  data  object  declarations  and  subprogram 
declarations.  A  package  is  referred  to,  within  the  code  of  some 
other  programming  unit,  by  means  of  a  USE  statement  that  effec- 
tively  inserts  the  "packaged"  statements.   Thus  a  package  is  not 
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directly  executable,  but  rather  contains  executable  units  (pro- 
cedures and/or  tasks)  that  may  be  invoked  from  outside  the  pack- 
age. It  may,  however,  have  an  executable  initialization  com- 
ponent. A  package  may  be  divided  into  two  parts,  a  "specifica- 
tion" part  that  is  "visible"  to  the  external  environment,  and  a 
"body"  which  is  hidden  from  the  external  environment.  Thus  the 
"user"  of  the  package  can  only  access  the  material  exhibited  in 
the  specification  part. 

The  code  shown  is  not  exactly  ADA;  the  word  "parameters" 
would  have  to  be  replaced  by  the  actual  data  objects  being 
passed.  Double  dashes  indicate  the  start  of  comments  that  con- 
tinue until  the  end  of  the  line.  Not  shown  (because  it  is  not 
relevant  at  this  time)  is  the  declaration  of  private  data  types 
and  objects;  such  types  and  data  objects  would  be  known  to  the 
users  of  the  SPY-1  package  but  their  underlying  structural  com- 
ponents would  not  be  accessible.  The  definition  of  the  various 
procedures  will  be  shown  elsewhere. 

How  is  the  SPY-1  package  used  in  a  real  ADA  programming 
environment?  It  would  be  embedded  in  another  "AEGIS  package", 
where  it  would  be  one  of  several  packages,  along  with  other  code. 
This  is  beyond  the  scope  of  the  research  project  and  so  is  not 
pursued  further,  except  to  point  out  the  various  procedures  would 
be  invoked  from  within  the  encompassing  AEGIS  package. 

The  details  of  the  messages  that  can  be  sent  and  received  via 
the  procedures  and  the  corresponding  procedure  bodies  are 
described  in  a  corresponding  package  "body",  as  is  shown  in  List- 
ing  2.   This   is   a   companion   component   the      specification 
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package  shown  in  Listing  1;  together  they  will  completely   define 
the  SPY-1  package. 

PACKAGE  BODY  spy_l  IS 

—  Local  type  and  object  declarations  and 

—  definitions  of  the  five  procedures  whose 

—  headers  are  in  the  package  specification 

—  shown  in  Listing  1.  These  would,  in  turn, 

—  call  entry  points  in  the  task  immediately 

—  following. 

PROCEDURE  orts_interf ace  (...)  IS 

...      —  invoked  from  an  ORTS  task 
BEGIN 

•  •  • 

initial ization_command;  —  invokes  the 
—  spy_l_control  task 

•  •  • 

END  orts_interf ace; 
TASK  spy_l_control  IS 

—  procedure  and  entry  declarations,  etc. 
TYPE  ...    —  message  type  declarations 
ENTRY  ini tial izat ion_command ; 

ENTRY  task_command;  —  other  entries  symbolically 
END  spy_l_control ; 
TASK  BODY  spy_l_control  IS 

—  local  declarations 
BEGIN 

ACCEPT  initialization_command ;  —  from  the 

—  ORTS  interface  procedure  shown  above. 
LOOP 

SELECT 

ACCEPT  task_command ;  —  others 

•    •    • 

END  SELECT; 
END  LOOP; 
END  spy_l_control; 
BEGIN  —  initialization  part 

INITIATE  spy_l_control;     —  starts  this  task 
END  spy_l; 

Listing  2.  ADA  representation  of  SPY-1  package  body. 
The  program  shown  in  Listing  2  is  a  very  high  level  represen- 
tation  of   the  overall  SPY-1  system,  and  so  is  described  in  some 
detail  in  the  following  paragraphs.   Note  that  within   the   SPY-1 
package   body   the   executable   portion   consists  of  at  least  one 
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statement  (between  the  package  body  BEGIN  and  END  delimiters), 
namely  "INITIATE  spy_l_control " .  In  the  declarative  portion  of 
the  package  body  is  defined  the  "spy_l_control "  task  that  is 
started  by  the  initiate  command.  This  task  will  control  the 
overall  execution  of  the  SPY-1  system,  doing  most  of  what  the 
"ates"  component  would  do  in  the  current  SPY-1  system.  By  defini- 
tion a  task  is  a  procedure  that  executes  in  parallel  with  other 
procedures.  They  can  be  initiated  (started)  or  aborted  (stopped), 
and  can  be  made  to  coordinate  their  activities  with  other  pro- 
cedures. 

Thus  a  controlling  task  is  started  from  the  SPY-1  package 
body,  and  so  execution  of  the  task  body  also  shown  in  Listing  2 
is  initiated.  The  first  statement  within  the  task  body  is  an 
"ACCEPT  initialization_command"  statement.  An  ACCEPT  statement 
forces  a  "rendezvous"  with  another  task  or  procedure  that  is  exe- 
cuting a  corresponding  "call"  statement.  The  label 
" initialization_command"  is  an  entry  point  in  the  spy_l_control 
task,  and  is  called  from  one  (or  more)  of  the  procedures  speci- 
fied in  Listing  1.  As  shown  in  Listing  2  the  entry  point  is 
called  indirectly  from  a  task  in  ORTS  (Operational  Readiness  Test 
System,  another  component  of  the  AEGIS  system).  Until  the  ren- 
dezvous is  accomplished  the  calling  procedure  is  halted;  in  this 
case  the  spy_l_control  task  tests  for  an  appropriate  initializa- 
tion command  (indirectly  received  from  ORTS);  it  does  not  proceed 
until  the  command  arrives.  In  the  example  shown  no  messages  (in 
the  form  of  a  parameter  list)  are  passed  between  calling  and 
called  tasks;  this  additional  detail  will  be  added  later. 
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When  the  initialization  command  is  received  the  rendezvous  is 
said  to  have  occured,  and  after  some  processing  in  the 
spy_l_control  task  both  the  calling  and  called  tasks  or  pro- 
cedures are  allowed  to  proceed  independently  of  each  other.  As 
shown  in  Listing  2,  this  results  in  the  entering  of  an  infinite 
loop  (LOOP  END  LOOP  statements) .  It  is  not  really  an  infin- 
ite loop  because  the  loop  body  contains  other  ACCEPT  statements, 
shown  symbolically  by  the  "ACCEPT  task_command"  statement.  In 
this  manner  other  SPY-1  tasks  are  initialized,  coordinated,  and 
aborted.  These  other  tasks  are  discussed  in  a  following  section. 

V  The  Rendezvous  Concept 

It  is  important  that  the  rendezvous  concept  be  fully  under- 
stood before  proceeding.  Consider  two  programs  (modeling  some 
procedures)  that  require  interaction  to  accomplish  some  common 
goal.  Typically  one  program  may  want  to  invoke  the  other  program 
to  carry  out  some  specific  job  on  its  behalf. 

Several  mechanisms  for  accomplishing  this  interaction  have 
been  devised.  ADA  adopts  a  "rendezvous"  concept,  in  which  a  cal- 
ling program  must  know  something  about  the  program  it  wishes  to 
invoke,  but  in  which  the  called  program  need  not  know  anything 
about  the  calling  program.  Thus  the  mechanism  is  one  sided  in 
that  sense.  This  is  clearly  superior  to  a  symmetrical  situation 
where  both  parties  to  the  interaction  must  know  of  each  other; 
the  rendezvous  concept  allows  a  library  of  programs  to  exist  and 
be  called  as  needed,  whereas  the  symmetrical  mechanism  does  not. 
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Consider  the  situation  in  which  a  data  structure  represents 
some  entity  that  must  undergo  certain  processing  during  its 
existence.  In  a  grocery  store  context  a  customer  may  require  the 
services  of  a  checkout  stand,  for  example.  Here  the  customer  must 
enter  a  queue  (possibly  empty)  to  await  his  turn  for  service. 
While  waiting  the  customer  is  necessarily  idle,  in  the  sense  he 
can  not  do  additional  shopping  or  anything  else.  When  prior  cus- 
tomers have  been  serviced  the  particular  customer  may  be  pro- 
cessed (a  modification  of  the  data  structure)  and  then  released 
to  some  other  environment.  In  the  modeling  technique  used  here  we 
say  a  customer  attempts  a  rendezvous  with  the  server;  if  the 
server  is  not  available  then  the  calling  entity  must  wait. 

The  rendezvous  technique  provides  additional  mechanisms 
allowing  priority  queues,  pre-emption,  and  availability  of  a  set 
of  resources  to  determine  service  response.  None  of  these  is  dis- 
cussed in  this  report.  However  the  rendezvous  concept  allows 
classical  problems  such  as  the  consumer-producer,  reader-writer, 
dining  philosophers,  etc.  to  be  modelled  in  a  straightf oward 
manner . 

Again  the  reader  is  reminded  that  nothing  in  the  notation 
dictates  anything  about  the  underlying  implementation  of  the 
model  on  a  real  set  of  computers.  Thus  it  is  not  meaningful  to 
consider  (at  this  stage)  when  or  how  programs  are  executed;  they 
are  just  executed  according  to  the  semantics  of  the  ADA-like 
language . 

VI  The  SPY-1  Control  Task 
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In  this  section  the  overall  structure  of  the  SPY-1  radar 
control  mechanism  is  described. 

The  situation  to  this  point  is  as  follows:  within  the  SPY-1 
package  a  "spy_l_control"  task  is  initiated  and  waits  for  an  ini- 
tialization command  from  one  of  the  specified  procedures.  When 
an  initialization  command  arrives  the  controlling  task  resumes 
execution  and  enters  an  infinite  loop  that  contains  a  SELECT 
statement  that  selects  among  any  rendezvous  request  corresponding 
to  the  ACCEPT  statements.  In  this  manner  the  various  component 
tasks  within  the  SPY-1  system  are  initiated,  aborted,  or  coordi- 
nated as  necessary.  The  various  messages  oassed  among  the  tasks 
have  not  yet  been  explicity  shown. 

We  now  address  the  internal  structures  of  the  SPY-1  radar 
system.  It  can  be  thought  of  as  consisting  of  various  tasks, 
executing  in  parallel  but  in  a  coordinated  fashion,  each  sending 
and  receiving  certain  messages.  Most  of  this  message  passing  and 
coordination  is  strictly  from  within  the  SPY-1  system,  but  in 
addition  there  is  the  external  communication  and  coordination 
with  the  other  AEGIS  system  components.  It  is  the  latter  that  is 
of  primary  interest  here;  we  are  most  concerned  in  modeling  the 
interface  of  SPY-1  with  these  other  components,  and  in  particular 
the  logical  relationships  of  the  interfaces  and  the  internal 
tasks.  Recall  that  it  is  precisely  these  relationships  that  are 
significant  in  the  early  design  stages,  and  that  it  is  a  premise 
of  this  research  project  that  conventional  notations  are  weak  in 
this  regard,  and  that  the  modeling  technique  used  here  would  be 
an  improvement. 
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SPY-1  must  interface  with  five  external  AEGIS  components  as 
is  shown  by  Listing  1:  command  and  decision,  weaDons  control, 
operational  readiness  and  testing,  gun  fire  control,  and  AEGIS 
tactical  executive  systems.  Each  of  these  interfaces  consists  of 
several  different  message  types.  Each  different  message  type 
requests  some  particular  service  from  the  SPY-1  radar  system. 
One  example  was  already  illustrated  in  the  previous  section  by 
the  initialization  command  indirectly  from  ORTS .  Consider  now  how 
these  messages  might  be  modelled  in  an  ADA-like  notation. 

The  referenced  source  document  indicates  how  the  various 
messages  are  transmitted  through  the  several  interfaces;  here  we 
concentrate  upon  the  unclassified  ones.  For  example  Tables 
3.4.17-1  and  3.4.17-III  in  the  reference  document  indicate  the 
inputs  and  outputs,  respectively,  of  the  command  and  decision 
interface.  Each  of  the  message  types  has  a  description  of  its 
message  content  fields,  scaling  precision,  data  rate,  conditions, 
operator  intervention  requirement,  and  its  destination  or  source; 
these  are  now  modelled  in  an  ADA-like  notation. 

According  to  the  reference  document,  one  of  the  message  con- 
tent fields  is  a  "message  type"  field;  presumably  it  is  this 
field  that  designates  any  particular  message  as  containing  data 
of  a  particular  format.  In  the  modeling  technique  employed  here 
it  is  only  necessary  to  use  the  contents  of  this  field  to  charac- 
terize the  record.  This  can  be  accomplished  by  using  a  record 
structure  of  the  "variant"  type,  in  which  a  particular  value  of  a 
variable  indicates  the  record  structure  that  follows.  In  this 
SPY-1  model  we  choose  to  define  separate  record   types   for   each 
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interface,  and  indeed  for  each  direction  of  data  flow  within  each 
interface.  This  is  done  so  that  the  semantics  of  the  modeling 
notation  can  be  used  to  our  advantage,  namely  the  ability  of 
"strong  type  checking"  to  enforce  only  legal  sending  and  receiv- 
ing of  messages. 

TYPE  c&d_interface_input  IS 
RECORD 

kind  :  (track_data,  data_ack,  burnthrough_rpt , 

track_acc_re j ,  radar_status ,  burnthrough_acc_re j , 
redundant_track ,  radar_load_status ,  rsc_status, 
radar_doctr ine) ;   —  an  enumerated  data  type 
CASE  kind  OF 

WHEN  track_data  => 

...    —  various  field  declarations 
WHEN  data_ack  => 

...    —  varous  field  declarations 


WHEN  radar_doctr ine  => 

...    —  various  field  declarations 
END  CASE; 
END  RECORD; 

Listing  3.  A  variant  record  declaration. 

An  example  of  the  variant  record  structure  mechanism  is 
shown  in  Listing  3.  The  record  structure  consists  of  a  field 
indicating  the  kind  of  message  stored  in  the  remaining  part  of 
the  structure,  in  this  situation  depending  upon  the  value  of  the 
variable  "kind";  each  "when  clause"  declares  the  fields  within 
each  message  type  (not  shown  in  Listing  3;  see  the  appendix  for  a 
complete  example) .  Similar  record  structures  are  defined  for  the 
command  and  decision  output  messages,  and  for  all  the  other 
interfaces . 

The  record  definition  described  above  is  of  a  tyoe  of   record. 
In  any  particular  procedure  or  task  variables  of  that  type  may  be 
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declared  and  then  manipulated  as  appropriate.  For  example,  in  a 
sending  procedure  the  declaration  of  a  variable  "message"  (by  a 
"message  :  c&d_interf ace_input "  statement)  might  be  used  to 
define  a  particular  data  structure  in  which  its  component  fields 
can  be  assigned  specific  values.  The  message  could  be  sent  by 
invoking  an  appropriate  procedure: 

c&d__user_services_input  (message  :  OUT  c&d_interf ace_input) ; 

Here  a  procedure  or  task  entry  name  is  written  followed  by  its 
output  argument  list;  the  "user  services"  notation  is  from  the 
reference  document.  The  direction  of  data  flow  is  "out"  from  the 
calling  procedure's  point  of  view.  The  "c&d_user_services_input " 
entry  name  (or  point)  must  be  declared  somewhere  in  an  appropri- 
ate task  or  procedure. 

Before  revising  Listing  1  to  include  message  parameter 
detail,  a  convenient  form  of  grouping  related  information  is 
employed  that  enables  only  important  details  to  be  exhibited  at  a 
particular  place.  The  less  important  detailed  information  is 
placed  elsewhere.  Listing  4  shows  a  package  of  type  statements, 
each  type  declaration  is  a  record  definition  similar  to  that 
shown  in  Listing  3.  Details  of  the  variant  record  structure  are 
omi  tted . 

Listing  5  shows  a  redefinition  of  the  SPY-1  package  specifi- 
cation shown  in  Listing  1.  Here  particular  procedure  headings  are 
defined  to  include  the  interfaces  in  both  directions.  This  allows 
messages   to   be  sent  in  either  direction  without  any  interdepen- 
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PACKAGE  interface_types_package  IS 
TYPE  c&d_interf ace_input  IS 

—  a  variant  record  structure 
TYPE 


TYPE 

•  ♦ 

TYPE 

•  • 

TYPE 
TYPE 
TYPE 
TYPE 
TYPE 
TYPE 


c&d_interf ace_output  IS 
wcs_interf ace_input  IS 
wcs_interf ace_output  IS 
orts_interf ace_input  IS 
orts_interf ace_output  IS 
qfcs_interface_intput  IS 
gf cs_interf ace_output  IS 
ates_interf ace_input  IS 
ates  interface  output  IS 


END  interf ace_types_package; 

Listing  4.  A  package  of  data  type  definitions, 
dence  upon  each  other.  These  ten  procedures  replace  the  five  pro- 
cedures of  Listing  1.  A  corresponding  redefinition  of  the  pro- 
cedure bodies  (which  are  enclosed  within  the  package  body)  would 
be  required.  Within  each  procedure  body  a  message  type  would  be 
determined  and  an  appropriate  entry  point  of  the  controlling  task 
called,  where  in  turn  other  appropriate  task  entry  points  may  be 
called,  thereby  forcing  appropriate  SPY-1  services  to  be  accom- 
plished. 

Again  the  private  type  definitions  are  omitted  because  they 
represent  internal  data  structures  not  needed  by  the  interface 
with  the  other  AEGIS  components.  Note  the  use  of  the  USE  state- 
ment to  enable  the  bulky  definitions  to  be  placed  elsewhere  (in  a 
separate  package) . 
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PACKAGE  spy_l  IS 

USE  interf ace_types_package; 
PROCEDURE  c&d_user_services_input 

(m  :  IN  c&d_interf ace_input) ; 
PROCEDURE  c&d_user_services_output 

(m  :  OUT  c&d_interf ace_output )  ; 
PROCUDURE  wcs_user_services_input 

(m  :  IN  wcs_interf ace_input)  ; 
PROCEDURE  wcs_user_services_output 

(m  :  OUT  wcs_interf ace_output) ; 
PROCEDURE  orts_user_services_input 

(m  :  IN  orts_interf ace_input)  ; 
PROCEDURE  orts_user_services_output 

(m  :  OUT  orts__interf  ace_output)  ; 
PROCEDURE  gfcs_user_services_input 

(m  :  IN  gfcs_interface_input) ; 
PROCEDURE  gfcs_user_services__output 

(m  :  OUT  gf cs_interf ace_output) ; 
PROCEDURE  ates_user_services_input 

(m  :  IN  ates_interf ace_input) ; 
PROCEDURE  ates_user_services_output 

(m  :  OUT  ates_interf ace_output) ; 
PRIVATE 

—  declaration  of  private  data  types 
END  spy_l; 

Listing  5.  A  revision  of  Listing  1. 

We  now  address  the  internal  tasks  of  SPY-1.  Previously  a 
"spy_l_control"  task  was  defined  and  indicated  that  it  controlled 
and  coordinated  other  tasks  by  means  of  ACCEPT  statements  embed- 
ded within  an  infinite  loop. 

Section  3.3.5.2  of  the  reference  document  lists  the  various 
functions  performed  by  the  SPY-1  radar.  These  functions  are 
divided  into  two  groups:  a  "tactical  function  group"  and  an  "ele- 
ment test  function  group".  These  are  shown  in  Tables  1  and  2, 
respectively. 

Listing  6  shows  a  skeleton  representation  of  a  SPY-1  func- 
tion in  the  form  of  a  task.  Entry  points  (not  explicitly  shown) 
indicating    how   external    tasks    may    interact   with    the 
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Initial ization 

Search  Management 

Track  Management 

Frequency  Management 

Radar  Scheduling 

Cross  Gating 

Beam  Stabilization 

Radar  Input  Processing 

Radar  Output  Processing 

Detection  Processing 

Track  Processing 

ECM/Clutter  Processing 

Track  Association 

Load  Evaluation 

Missile  Communications 

Historical  Recording 

Switch  Action  and  Display  Processing 

Video  Formatter 


Table  1.   SPY-1  Tactical  Functions. 
"search_management"  task  are  of  crucial  importance;  the  reference 
document   (or   at   least  the  unclassified  part)  does  not  indicate 
these  details.   Similar  tasks  would  be  defined  for  all  the   func- 
tions listed  in  Tables  1  and  2. 

It  is  not  important  at  this  stage  of  modeling  to  know  the 
details  of  how  these  functions  work;  the  statement  of  what  must 
be  accomplished  is  of  higher  priority  at  the  early  design  stages. 
However  it  is  the  correct  interaction  of  these  functions  that  is 
the  next  highest  priority,  certainly  higher  priority  than  the 
details  of  their  algorithms.  For  this  reason  we  now  address  the 
interaction  of  these  functions. 

The  ramification  of  modeling  the  interactions  is  the  defin- 
ition in  the  ADA-like  notation  of  task  entry  points  that  can  be 
called  in  the  SELECT  statement  in  the  "spy-1-control "  task  of 
Listing  2.  The  placement  of  the  calls  to  these  other  tasks  within 
the  various  select  clauses  describes  the   manner   of   interaction 
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EFT  Control 

Dynamic  Test  Targets 

Operability  and  Performance  Testing 

Angle  Calibration  Testing 

On-Line  Scan  Tests 

Transmitter  Power  and  Phase  Test 

Signal  Processor  Fault  Isolation  Support  Testing 

Nonmission  Tests 


Table  2.  SPY-1  Element  Test  Functions 
allowed,  and  the  parameter  lists  indicate  the   transfer   of   mes- 
sages  between   the   tasks.   Before  describing  the  SPY-1  radar  in 
this  notation  a  review  of  the  ADA  notation  is  presented. 

Recall  that  tasks  execute  in  parallel  with  other  tasks,  and 
that  they  contain  explicit  entry  points,  and  that  each  entry 
point  can  optionally  have  a  parameter  list  that  affects  intertask 
communication.  From  within  a  particular  task  (or  procedure) 
another  task  may  be  invoked  or  called,  forcing  it  (the  calling 
task)  to  halt  execution  until  a  rendezvous  with  the  called  task 
can  legally  occur.  Meanwhile,  in  the  called  task,  execution  con- 
tinues until  the  internal  logic  indicates  that  the  current  execu- 
tion is  completed.  At  that  moment  the  calling  and  called  tasks 
can  legally  attempt  synchronization  and,  if  possible,  a  rendez- 
vous is  said  to  occur.  The  SELECT  statement  in  the  called  task 
allows  the  rendezvous  to  happen  by  selecting  the  corresponding 
ACCEPT  statement  clause  to  be  executed;  the  select  mechanism  can 
force  the  calling  task  to  remain  halted  while  some  particular 
code  is  being  executed,  after  which  both  tasks  may  proceed  on 
their  independent  ways.  Possibly  some  additional  code  in  the 
coordinating  task  may  be  executed  prior  to  the  next  selection  by 
the    SELECT   statement.   The   continuing   selection   process   is 
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TASK  search_management  (...)  IS 

—  include  any  specification  details 

—  here  such  as  type  specifications, 

—  subprogram  specifications,  and 

—  entry  point  specifications. 
END; 

TASK  BODY  search_management  IS 

—  local  declarations 
BEGIN 

—  a  select  statement  within  an  infinite 

—  loop  accepts  calls  to  this  task's  entry 

—  points,  which  when  undertaken  effect 

—  various  actions  on  part  of  the  SPY-1 

—  system. 
END; 


Listing  6.  A  representation  of  a  SPY-1  function, 
accomplished  because  (in   this   case)   the   SELECT   statement   is 
embedded  in  an  infinite  loop. 

The  reference  document  does  not  explicitly  indicate  the 
manner  in  which  the  various  functions  may  legally  interact, 
prohibiting  the  exact  representation  of  this  process  in  the  ADA- 
like  notation.  Figures  3.3.5.3-3  through  3.3.5.3-7  in  the  refer- 
ence document  do  indicate  in  block  diagram  form  the  flow  of 
interf unction  data  (messages)  among  the  various  functions.  At 
any  rate  the  exact  sequencing  among  the  functions  is  believed 
classified  and  so  would  not  be  accessible  to  this  study  in  any 
case . 

However,  since  this  part  of  the  system  model  is  so  vital  to 
the  correct  derivation  of  any  complex  system  (such  as  SPY-1)  and 
is  so  much  an  important  point  underlying  the  usefulness  of  the 
notation,  a  fictitious  characterization  of  the  interaction  is 
presented.  It  is  included  to  illustrate  how  the  notation  would 
appear,   and  is  not  to  be  construed  to  be  an  accurate  representa- 
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tion  of  how  the  SPY-1  radar  system  really  works.  Listing  7  indi- 
cates how  the  various  functional  tasks  might  be  coordinated  by 
the  ADA-like  notation. 

—  appears  in  the  body  of  "spy_l  control"  task 

LOOP  —  an  infinite  loop  structure 

SELECT       —  this  statement  selects  among 

—  the  various  "accept"  statements, 

—  each  of  which  represents  a  task 

—  entry  point;  note  some  are 

—  are  "guarded"  by  a  "when"  statement 
ACCEPT  f requency_change_request  (...)  DO 

—  these  statements  are  executed  before 

—  the  rendezvoused  tasks  are  allowed 

—  to  proceed  independently 
END; 

—  these  statements  are  executed  before 

—  any  other  selection  of  a  rendezvous; 

—  typically  other  tasks  may  be  called 

—  upon  to  provide  some  kind  of  service. 
OR  ACCEPT  track  start  request  (...)  DO 


END; 


OR  WHEN  dwell_time_expired  ACCEPT 
next_beam_request  (...)  DO 

—  this  is  an  example  of  a  guarded 

—  rendezvous;  the  condition  must 

—  be  true  before  a  rendezvous  may 

—  occur 

•  •  • 

END; 

•  •  • 

—  other  guarded  or  unguarded  accept  statements 
END  SELECT; 
END  LOOP; 

Listing  7.  Fictitious  SPY-1  control  task  representation. 

Within  the  SELECT  statement  a  series  of  guarded  and  unguarded 
ACCEPT  statements  indicate  the  proper  coordination  and  data 
transfer  permitted  among  the  various  tasks.  Guarded  ACCEPT  state- 
ments  (having   the  WHEN  predicate)  permit  a  rendezvous  only  when 
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the  predicate  is  true.  In  general  all  tasks  are  executing  in 
parallel,  but  are  coordinated  by  the  "spy_l_control "  task  of 
which  Listing  7  is  but  a  part.  Because  the  SELECT  statement  is  in 
an  infinite  loop,  the  controlling  task  is  always  "checking"  for 
the  next  possible  rendezvous,  when  more  than  one  rendezvous  is 
possible  any  particular  one  is  selected  at  random.  If  no  rendez- 
vous is  possible  (because  none  is  being  requested  or  guard  predi- 
cates are  false)  the  controlling  task  just  waits.  Not  shown  in 
Listing  7  is  a  particular  ACCEPT  clause  that  would  allow  an  ORTS 
task  (or  procedure)  to  abort  or  kill  the  SPY-1  radar  system, 
effectively  causing  it  to  exit  the  infinite  loop  structure.  An 
alternative  notation  for  expressing  the  synchronization  of  tasks 
is  presented  in  [Andler79] ;  it  has  the  advantage  of  being  more 
succinct. 

ACCEPT  f requency_change_request  (m  :  IN  c&d_interf ace_input)  DO 
saved_message  :=  m; 
END;      —  calling  task  or  procedure  may  now  continue 

—  interpret  the  message  and  invoke  the  appropriate 

—  set  of  internal  tasks  such  that  the  request  is 

—  carried  out;  fictitious  tasks  are  illustrated  here 
CASE  saved_message . request  OF 

WHEN  phase_change  => 

change_phase  (saved_message. rate) ;  —  task  invoked 

video_formatter  ("phase  changed");  —  to  operator 
WHEN  freq_change  => 

change_f requency  (saved_message .value) ; 

video_formatter  ("frequency  changed"); 
WHEN  ... 

•  •  • 

END  CASE; 

—  this  is  the  end  of  the  accept  clause 

—  another  rendezvous  may  be  selected 

Listing  8.  Fictitious  detail  added  to  a  component  of 
Listing  7. 

A    further    fictitious     expansion     of     the     ACCEPT 
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f requency_change_request  clause  portion  of  Listing  7  is  shown  in 
Listing  8.  Again  the  general  process  is  reviewed:  some  task 
external  to  the  SPY-1  environment  makes  a  request  for  a  SPY-1 
service  by  invoking  one  of  the  procedures  specified  in  the  SPY-1 
package  specification.  For  example  the  Command  and  Control  com- 
ponent may  request  a  frequency  change  by  invoking  the 
"c&d_user_services_input "  procedure  with  an  appropriate  message 
argument.  Within  this  procedure  the  message  is  interpreted  and  an 
appropriate  SPY-1  internal  function  is  invoked  by  calling  an 
entry  point  in  the  spy_l_control  task,  whose  sole  purpose  is  to 
coordinate  all  such  requests.  When  the  spy_l_control  task  accepts 
the  call  (a  rendezvous)  the  message  is  saved  in  a  local  variable, 
and  then  the  calling  procedure  is  released  which  in  turn  can 
release  the  task  in  the  command  and  control  component  of  AEGIS. 
Meanwhile,  in  the  spy_l_control  task  the  accept  clause  is  con- 
tinuing execution.  As  shown  is  Listing  8  the  particular  request 
may  be  determined  by  a  CASE  statement,  where  the  appropriate  WHEN 
clause  can  invoke  some  set  of  SPY-1  internal  tasks  (those 
corresponding  to  the  functions  listed  in  Tables  1  and  2) .  For 
example,  in  Listing  8,  if  the  " f req_change"  clause  is  executed 
two  (fictitious)  subtasks  of  the  Frequency  Management  function 
are  invoked,  presumably  adequate  for  carrying  out  the  requested 
service.  At  this  time  the  SELECT  statement  may  select  another 
pending  request  for  service. 

Even  though  the  reference  document  does  not  contain  enough 
unclassified  information  to  permit  the  representation  of  this 
controlling  task,  it  is  restated  again  that  it  is  precisely   this 
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aspect  of  the  early  design  stages  that  is  among  the  most  essen- 
tial to  a  successful  design  of  a  complex  interactive  system,  and 
that  the  advantage  of  the  ADA-like  notation  proposed  here  is  that 
it  allows  such  a  representation. 

VII  Summary  and  Conclusions 


This  research  study  derived  an  ADA-like  model  of  the  SPY-1 
radar  system  to  the  extent  budgetary,  reference  documents,  and 
security  constraints  permitted.  The  model  is  confined  to  the  very 
highest  level,  for  it  is  at  this  level  that  both  system  designers 
and  system  buyers  (customers)  must  mutually  understand  their  sys- 
tem problems.  It  is  at  this  level  that  complex  system  designs 
usually  deviate  from  the  path  that  would  lead  directly  to  a  suc- 
cessful system,  primarily  due  to  poor  specification  and  under- 
standing of  the  buyer's  problem.  The  buyer  is  usually  not  in  the 
position  to  prohibit  the  deviation  because  they  are  not  (at  that 
time)  aware  of  it.  By  the  time  the  existence  of  the  deviation  is 
known  to  either  party,  much  time  and  effort  is  usually  wasted, 
and  additional  time  and  effort  is  expended  attempting  to  rectify 
the  inappropriately  designed  system. 

The  assertion  here  is  that  a  better  high  level  modeling 
technique  could  at  least  alleviate  the  problem,  by  forcing  the 
explicit  concentration  of  effort  on  the  proper  specification  of 
the  system's  high  level  design,  and  in  a  format  easily  under- 
standable by  both  designers  and  the  customers,  ^n  ADA-like  nota- 
tion  is   proposed,   because   it   embodies   those  characteristics 
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important  to  specification  engineering,  is  (or  will  be)  a  nota- 
tion familiar  to  both  designers  and  customers,  is  amenable  to 
machine  processing  to  ascertain  design  completeness  and  con- 
sistency, and  will  be  used  (by  DoD  policy)  in  the  actual  coding 
of  the  logic. 

Is  the  model  presented  here  for  the  SPY-1  radar  system  a 
convincing  argument  for  the  usefulness  of  the  notation?  The  goal 
of  this  research  is  not  to  definitively  answer  this  question,  but 
to  illustrate  the  proposition,  and  to  assess  the  utility  of  the 
technique  in  a  nonquanti tative  manner.  It  is  suggested  here  that 
the  proposed  technique  does  satisfy  a  nonquanti tative  assessment 
of  its  utility,  by  the  clarity  of  the  representation  of  SPY-1  as 
shown  in  the  previous  sections  and  again  in  the  appendix.  Only 
more  examples  of  the  method,  done  by  several  independent  study 
groups  and  over  a  period  of  time,  can  provide  data  so  that  the 
usefulness  of  the  technique  can  be  adequately  assessed.  It  is 
recommended  that  further  study  be  undertaken  for  this  purpose. 

A  further  qualifying  statement  must  be  made.  ADA  is  undergo- 
ing (at  the  time  of  writing)  a  final  revision  of  its  definition, 
and  so  it  is  possible  (and  even  probable)  that  some  portions  of 
ADA  illustrated  here  may  not  remain  in  the  final  definition  of 
the  language.  This  is  one  more  reason  for  further  study  of  the 
usefulness  of  the  modeling  technique  proposed  here. 
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APPENDIX 


This  appendix  lists  the  final  form  of  the  ADA-like  model  of 
the  SPY-1  radar  system  developed  over  the  course  of  the  research. 
The  extent  of  the  model  is  limited  due  to  the  available  reference 
document  and  to  the  amount  of  manpower  used.  The  model  is  res- 
tated here  to  bring  the  various  component  parts  of  the  SPY-1,  as 
presented  in  the  body  of  the  report,  into  one  place  where  a  qual- 
itative assessment  as  to  its  usefulness  can  more  easily  be  made. 

Subordinate  packages  used  with  the  "spy_l"  package  are  placed 
at  the  end  of  this  appendix,  where  they  can  be  easily  referred 
to.  The  main  package  can  be  usefully  studied  with  only  occasional 
reference  to  the  subordinate  packages. 
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—  the  following  package  is  to  be  "used" 

—  in  an  encompassing  AEGIS  package 

PACKAGE  spy_l  IS 

—  the  following  package  contains 

—  type  definitions  for  all  messages 
USE  interface_types_package; 

—  all  the  following  procedures  are  callable  from 

—  the  encompassing  AEGIS  package  and  effect 

—  all  SPY-1  services  to  AEGIS 
PROCEDURE  c&d_user_services_input 

(m  :  IN  c&d_interf ace_input) ; 
PROCEDURE  c&d_user_services_output 

(m  :  OUT  c&d_interf ace_output ) ; 
PROCEDURE  wcs_user_services_input 

(m  :  IN  wcs_interf ace_input) ; 
PROCEDURE  wcs_user_services_output 

(m  :  OUT  wcs_interf ace_output) ; 
PROCEDURE  orts_user_services_input 

(m  :  IN  orts_interf ace_input) ; 
PROCEDURE  orts_user_services_output 

(m  :  OUT  orts_interf ace_output) ; 
PROCEDURE  gfcs_user_services_input 

(m  :  IN  gfcs_interface_input) ; 
PROCEDURE  gfcs_user_services_output 

(m  :  OUT  gfcs_interf ace_output) ; 
PROCEDURE  ates_user_services_input 

(m  :  IN  ates_interf ace_input) ; 
PROCEDURE  ates_user_services_output 

(m  :  OUT  ates_interf ace_output) ; 
PRIVATE 

—  declaration  of  private  data  types 

—  probably  not  needed  in  this  package 
END  spy  1;       —  the  specification  part 
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PACKAGE  BODY  spy_l  IS 
—  all  local  declarations 

USE  interf unction_interf aces;  —  a  package 
PROCEDURE  BODY  c&d_user_services_input  IS 

—  all  local  declarations 
BEGIN 

—  interpret  the  message  and  invoke  appropriate 

—  SPY_1  control  task  entry  points,  where 

—  appropriate  functional  tasks  will  be  invoked 

—  to  carry  out  the  request 


CASE  m.kind  OF 

WHEN  change_mode  => 

—  request  rendezvous  with  spy_l  control 
track_start_request  (..);  — possibly  with  argument 

WHEN  change  status  => 


END  CASE; 

•  •  • 

END  c&d  user  services  input; 
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—  the  rema 

—  separate 
PROCEDURE  B 
PROCEDURE  B 
PROCEDURE  B 
PROCEDURE  B 
PROCEDURE  B 
PROCEDURE  B 
PROCEDURE  B 
PROCEDURE  B 
PROCEDURE  B 


ining  procedures  are  left  as 
ly  compiled  entities,  not  shown 
ODY  c&d_user_services_output  IS 
ODY  wcs_user_services_input  IS 
ODY  wcs_user_services_output  IS 
ODY  orts_user_services_input  IS 
ODY  orts_user_services_output  IS 
ODY  gfcs_user_services_input  IS 
ODY  gfcs_user_services_output  IS 
ODY  ates_user_services_input  IS 
ODY  ates  user  services  output  IS 


in  appendix 
SEPARATE 
SEPARATE 
SEPARATE 
SEPARATE 
SEPARATE 
SEPARATE 
SEPARATE 
SEPARATE 
SEPARATE 


—  SPY-1  control  task  follows;  schedules  all 

—  requests  for  services  coming  via  the  above  procedures 
TASK  spy_l_control  IS 

—  entry  point  definitions  follow 

ENTRY  ini tial iza tion_command  (m:  IN  orts_interf ace_input) ; 
ENTRY  f requency_change_request  (...); 
ENTRY  track_start_request  (...); 
ENTRY  next_beam_request  (...); 

—  all  others  entry  declarations 

—  and  other  declarations 

END  spy_l_control;     —  the  specification  part 
TASK  BODY  spy_l_control  IS 
—  local  declarations 
BEGIN 

ACCEPT  initialization_command (...); 

—  indirectly  from  ORTS  via 

—  orts_user_services_input  procedure 

—  actually  there  is  several  kinds 

—  of  initialization  commands  possible 

—  in  SPY-1,  but  are  not  indicated  here 
INITIATE  search_management ,  track_management , 

radar_scheduling ,  cross_gating , 

beam_stabi  lization,  radar__input_processing  , 

radar_output_processing ,  detection_processing , 

track_processing ,  ecm_clutter_processing , 

track_association ,  load_evaluation , 

missile_communication ,  histor ical_recording , 

switch_action_display_processing , 

video_formatter ,  eft_control,  dynamic_test_targets, 

operabili ty_performance_testing , 

angle_cal ibration_test ing ,  onl ine_scan_tests , 

transmi tter_power_phase_test , 

signal _processor_f ault_i sol at ion_support_te sting , 

nonmission_tests; 

—  and  whatever  subtasks  are  needed 
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LOOP        —  an  "infinite"  loop  entered 
SELECT   —  an  accept  clause  for  every 
—  entry  point 
ACCEPT  f requency_change_request 

(m  :  IN  c&d_interface_input)  DO 
saved_message  :=  m; 
END;  —  calling  procedure  may  continue 

—  interpret  the  message  and  invoke 

—  the  appropriate  set  of  internal 

—  tasks  such  that  the  request  is 

—  carried  out;  fictitious  tasks 

—  are  illustrated  here 

CASE  saved_message. request  OF 
WHEN  phase_change  => 

change_phase  (saved_message. rate)  ; 

video_formatter  ("phase  changed"); 
WHEN  freq_change  => 

change_f requency  (saved_message .value) ; 

video_formatter  ("frequency  changed"); 
WHEN  .  .  . 


END  CASE; 

OR  ACCEPT  

OR  ACCEPT  

OR  WHEN ACCEPT 


END  SELECT; 
END  LOOP; 
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—  r 

—  c 
TASK 
TASK 
TASK 
TASK 
TASK 
TASK 
TASK 
TASK 
TASK 
TASK 
TASK 
TASK 
TASK 
TASK 
TASK 
TASK 
TASK 
TASK 
TASK 
TASK 
TASK 
TASK 
TASK 
TASK 


emainin 
ompiled 
search 
track_ 
f reque 
radar_ 
cross_ 
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radar_ 
radar_ 
detect 
track_ 
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missil 
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switch 
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dynami 
operab 
angle_ 
online 
transm 
signal 


TASK  nonmis 
—  and  what 


g  tasks  are 

units  not 
_management 
management 
ncy_managem 
scheduling 
gating 
tabilizatio 
input_proce 
output_proc 
ion_process 
processing 
utter_proce 
association 
valuation 
e_communica 
ical_record 
_action_dis 
formatter 
ntrol 

c_test_targ 
ility_perfo 
calibration 
_scan_tests 
i tter_power 
_processor_ 

sion_tests 
ever  subtas 


left 
shown 


ent 


n 

ssing 
essin 
ing 

ssing 


tions 

ing 

play 


as  separately 
in  appendix 

IS  SE 
IS  SE 
IS  SE 
IS  SE 
IS  SE 
IS  SE 
IS  SE 
g  IS  SE 

IS  SE 
IS  SE 
IS  SE 
IS  SE 
IS  SE 
IS  SE 
IS  SE 
processing  IS  SE 
IS  SE 
IS  SE 
IS  SE 
IS  SE 
IS  SE 
IS  SE 
a_phase_test  IS  SE 
f ault_isolation_suppo 

IS  SE 
IS  SE 
ks  are  necessary 


ets 
rmanc 
test 


e_testing 
ing 


PARATE 

PARATE 

PARATE 

PARATE 

PARATE 

PARATE 

PARATE 

PARATE 

PARATE 

PARATE 

PARATE 

PARATE 

PARATE 

PARATE 

PARATE 

PARATE 

PIRATE 

PARATE 

PARATE 

PARATE 

PARATE 

PARATE 

PARATE 

rt_testing 

PARATE ; 

PARATE; 


BEGIN      —  initialization  part  of  package 
INITIATE  spy_l_control; 
END  spy  1;    —  end  of  complete  SPY-1  package 


-  32  - 


—  the  interface  message  type  package 

—  all  the  following  is  from  the  reference 

—  document;  detailed  to  the  extent  given  there 

—  in  some  cases  the  detail  varys  slightly 

—  from  the  assumptions  used  in  the  model 


PACKAGE  interf ace_types_package  IS 

TYPE  c&d_interface_input  IS 
RECORD 
kind  :  (track_data,  data_ack,  burnthrough_rpt , 
track_acc_rej ,  radar_status ,  burnthrough_acc_re j , 
redundant_track ,  radar_load_status ,  rsc_status, 
radar_doctr ine) ; 
CASE  kind  OF    —  question  marks  indicate  unknown  types 
WHEN  track_data  => 
no_of_tracks  :  ???; 

O  Lbi      •      m      •      m      j 

control_grp_trk_no  :  ???; 
weapon_control_indexes  :  ???; 
time_lag  :  ???; 
ampli tude_estimates  :  ???; 
parent_ctsl  :  ???; 

type_track_indicators  :  (real,  simulated); 
position  :  ARRAY  (coordinates)  OF  REAL; 
velocity  :  ARRAY  (coordinates)  OF  REAL; 
slant_range  :  ???; 
slant_range_rate  :  ???; 
lost_track_indicator  :  ???; 
bearing_data  :  ???; 
elevation_data  :  ???; 
track_coast_count  :  ???; 
track_indicators  :  (old,  new); 
track_mode_indicators  :  (active,  passive, 
coverpulse,  missile); 

missile_indicator  :  ???; 

report_type  :  (normal,  special_threat) ; 
WHEN  data_ack  => 
ctsl  :  ???; 

control _gpr_trk_no  :  ???; 
range_rate  :  ???; 
status  :  (enable,  disable); 

min_bearing,  max_bearing  :  ???; 
min  range,  max  range  :  ???; 
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WHEN  burnthrough_rpt  => 

console_address  :  ???; 

ctsl  :  ???; 

control_grp_trk_no  :  ???; 

time_tag  :  ???; 

elevation  :  ???; 

bearing  :  ???; 

target_ranges  :  ARRAY  (no_of_targets)  OF  REAL; 
WHEN  track_acc_rej  => 

ctsl  :  ???; 

response_code  :  (accept,  busy,  illegal); 
WHEN  rsc_status  => 

control_grp_status  :  (start_up,  ready); 

radar_status  :  (fore_off,  £ore_standby , 
fore_ready,  f ore_radiate ,  aft_off, 
aft_standby,  aft_readyf  af t_radiate) ; 
WHEN  burnthrough_acc_rej  => 

c&d_trk_index  :  ???; 

control_grp_trk_no  :  ???; 

response_code  :  (accept,  busy,  illegal); 
WHEN  redundant_track  => 

O  L-  o  _L   •   •  •  •  / 

control_grp_trk_no  :  ???; 
WHEN  radar_load_status  => 

trk_f ile_percent_load  :  ???; 

radar_percent_load  ;  ???; 

control_grp_percent_load  :  ???; 

time_tag  :  ???; 

search_f rame_time  :  ???; 

radar_status  :  ???; 

percent_track_time  :  ??? 
WHEN  rsc_status  => 

console_address  :  ???; 

type_reply  :  (good,  bad,  missed); 
WHEN  radar_doctrine  => 

—  AN/SPY-1  doctrine  (not  given) 
END  CASE; 
END  RECORD; 
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TYPE  c&d_interf ace_output  IS 
RECORD 
kind  :  (track_id,  auto_mode_paraneters , 
cease_rpt_drop_trk ,  trk_acquisi tion_req, 
ships_speed,  burnthrough_req,  display_req, 
c&d_doctr ine_control ,  passive_trk_data , 
alert_pending) ; 
CASE  kind  OF 

WHEN  track_id  => 

L  Co  1   •    •  •  •  f 

weapon_control_index  :  ???; 

radar_set_trk_no  :  ???; 

category  :  (air,  surface,  clutter); 

id_class  :  (conf irmed_hostile, 

assumed_hostile ,  unknown,  assumed_f r iendly , 
conf i rmed_f r iendly ,  controlled_fr iendly) ; 

tactically_signif icant  :  ???; 
WHEN  auto_raode_parameters  => 

min_range_rate  :  ???; 

ending_bear ing ,  starting_bear ing  :  ???; 

min_range,  max_range  :  ???; 

status  :  (enable,  disable); 
WHEN  cease_rpt_drop__trk  => 

ctsl  :  ???; 

control_grp_trk_no  :  ???; 

weapon_control_index  :  ???; 

drop_trk_indicator  :  ???; 
WHEN  track_acquisi tion_req  => 

time_tag  :  ???; 

dimensional_indicator  :  (two_d,  three_d) ; 

position  :  ARRAY  (coordinates)  OF  REAL; 

velocity  :  ARRAY  (coordinates)  OF  REAL; 

ctsl  :  ???; 

weapon_control_index  :  ???; 

acquisi tion_indicator  :  (active,  passive, 
surface) ; 

asimuth_extent  :  (normal,  wide); 
WHEN  ships  speed  => 


x  dot,  y  dot 


•  •  '  i 
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WHEN  burnthrough_req  => 

control_grp_trk_no  :  ???; 

request_type  :  (high_vel,  low_vel); 

start_range  :  ???; 
WHEN  display_req  => 

console_address  :  ???; 

video_formatter_type  :  ???; 

header_code  :  ???; 

display_mode  :  (above_horiz ,  horiz_clear, 
hor iz_mti ) ; 
WHEN  c&d_doctr ine_control  => 

radar_silence  :  (on,  off); 
WHEN  passive_trk_range_data  => 

L  U  o  1   •    •  •  a  / 

radar_trk_no  :  ???; 
range  :  ???; 
range_rate  :  ???; 
time_tags  :  ???; 
data_source_id  :  ???; 
weapon_control_index  :  ???; 
associated_patl  :  ???; 
coast_count  :  ???; 
WHEN  alert_pending  => 
—  notice  of  alert 
END  CASE; 
END  RECORD; 
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PACKAGE  interf unction_interf aces  IS 

—  these  are  typical  of  the  data  structures 

—  used  for  internal  SPY-1  function  communication, 

—  and  are  included  here  for  illustrative  purposes 
TYPE  initialization_interf ace_input  IS 

RECORD 
kind  :  ( ini tialization_orders ,  test_results_summary , 

radar_status_summary ,  qryo_status_summary , 

ates_ini tial_complete ,  transmi tter_status , 

loop_closure_conf i rmation)  ; 
CASE  kind  OF 

WHEN  initialization_orders  => 

—  initialization  switch  actions 

—  details  not  known 
WHEN  test_results_summary  => 

—  results  of  CAL,  OPT,  OLS 
WHEN  radar_status_summary  => 

—  summary  of  radar  operable  units 
WHEN  gyro_status_data  => 

—  gyro  data  converter  and  gyro  status  data 
WHEN  ates_initial_complete  => 

—  indication  that  radar  initialization 

—  can  commence 

WHEN  transmitter_status  => 

—  transmitter,  status,  i.  e.,  standby 

—  ready,  (requested  and  received) 
WHEN  loop_closure_conf irmation  => 

—  notification  of  first  radar  return 
END  CASE; 

END  RECORD; 

TYPE  initialization_interf ace_output  IS 
RECORD 

kind  :  (xmtr_state,  etf_test_requests , 

request_start_gyro ,  radar_system_status) ; 
—  next  page  classified,  more  may  follow 
CASE  kind  OF 

WHEN  xmtr_state  => 

—  command  to  change  xmtr  state  up  or  down 
WHEN  etf__test_requests  => 

—  none  given  in  reference  source 
WHEN  request_start_gyro  => 

—  request  to  start  gyro  module 
WHEN  radar_system_status  => 

—  control  group  status/radar  system  status 

—  dedicated  etf-test  flag  or  normal  etf- 

—  test  priority 
END  CASE; 

END  RECORD; 
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TYPE  f requency_management_input  IS 
RECORD 

kind  :  (beam_posi tion ,  target_information , 
doctrine,  hardware_operabil i ty , 
missile_information) ; 
CASE  kind  OF    —  question  marks  mean  unkown  type 
WHEN  beam_posi tion  => 
bearing  :  ???; 
elevation  :  ???; 
sector  :  ???; 
subsector  :  ???; 
WHEN  target_information  => 
range_rate  :  ???; 
mode  :  ???; 
mti_pr i_index  :  ???; 
WHEN  doctrine  => 

—  frequency  doctrine 
fixed  :  ???; 
prelook  :  ???; 
random  :  ???; 

—  sector  doctrine 
min_max_bear ing  :  ???; 
excluded_f requency_channels  :  ???; 

—  baseline  doctrine 
excluded_f requency_channels  :  ???; 

WHEN  hardware_operability  => 

—  frequency  constrained  by  hardware 
WHEN  missile_information  => 

uplink_freq,  downl ink_f req  :  ???; 
END  CASE; 
END  RECORD; 
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TYPE  radar_scheduling_input  IS 
RECORD 
kind  :  (search_lists_special ,  radiation_doctr ine , 
time_sych,  track_beam_scheduled , 
ships_motion_matr ix ,  radar_silence , 
wavef orm_information ,  mode_status , 
xtmr_state,  track_time_counter_reset) ; 
CASE   kind  OF 
WHEN  search_lists_special  => 

—  HS  and  AHS  and  special  requests 
stc_data  :  ???; 

beam_posi tion  :  ???; 
blanking_gates  :  ???; 
clutter_gates  :  ???; 
mode  :  ???; 

instrurnented_range  :  ???; 
clutter_map_f lag  :  ???; 
end_of_f rame_f lag  :  ???; 
WHEN  radiation_doctr ine  => 

—  relative  bearings  of  radiation 

—  inhibit  sectors 
power_option  :  (high,  low,  off); 

WHEN  time_sync  => 

—  resynchronization  time 
WHEN  track_beam_scheduled  => 

—  track  numbers  by  priority 

—  track  file 

WHEN  ships_motion_matr ix  => 

—  stable  deck  orientation 

—  azimuth  limits  for  search  &  track 

—  azimuth  limit  slope 
WHEN  radar_silence  => 

—  radiation  inhibit 

WHEN  wavef orm_inf ormation  => 

—  frequency  channel  and  bands 

—  phase  code  pri  and  dwell  time  for  mti 
WHEN  mode_status  => 

—  waveform  substitution 
WHEN  xmtr_state  => 

—  xmtr  state 

WHEN  track_time_counter_reset  => 

—  reset  for  track  time  counter 
END  CASE; 

END  RECORD; 

—  all  the  remaining  interf unction  interfaces 
END  inter  function  interfaces; 
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